Elektronische Gesundheitskarte und Telematikinfrastruktur

Übergreifende Spezifikation

Performance und Mengengerüst TI-Plattform

    

     

      
Version
      
2.26.2
     
     

      
Revision
      
574294
     
     

      
Stand
      
10.02.2023
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_Perf
     
    

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

Die Performance-Spezifikation hat zum Ziel, die Performance-Kenngrößen für alle Produkttypen der TI zu definieren und die Anforderungen an die Performance der Produkttypen zu stellen. Ausgangspunkt für die Berücksichtigung des Bedarfs sind die Leistungsanforderungen für die Fachanwendungen, das sichere Übermittlungsverfahren KOM-LE, die Basisdienste QES, die tokenbasierten Authentisierung sowie für den Zugang zu Fremdnetzen (Internet, Bestandsnetz).

Die Performance-Kenngrößen decken drei Dimensionen ab:

• Durchsatz, die Anzahl an Funktionsaufrufen oder die Datenmenge, die pro Zeiteinheit durch das System oder eine seiner Komponenten abgearbeitet werden,
• die erlaubte Bearbeitungszeit je Funktionsaufruf und die
• Verfügbarkeit über die gesamte Betriebszeit.

Die Ableitung der Produktanforderungen erfolgt über ein Performance-Modell, das hier soweit skizziert wird, wie für die Nachvollziehbarkeit erforderlich.

Die Anforderungen an die Produkttypen sind so formuliert, dass sie dem Stand der Technik entsprechende Optimierungen implizit voraussetzen, aber nicht zwingendermaßen Vorgaben für konkrete Optimierungen machen. So wird das gewünschte Leistungsniveau erreicht, ohne dabei den Lösungsraum für die Anbieter unnötig einzuschränken. Spezifische Anforderungen zur Optimierung können allerdings in den produkttypspezifischen Spezifikationen gestellt werden.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller und Anbieter von Produkten der TI.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens.

Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungsverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

Schutzrechts-/Patentrechtshinweis

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Abgrenzung des Dokuments

Das vorliegende Dokument stellt Performance-Anforderungen an die technischen, aber nicht an organisatorische Schnittstellen der TI-Plattform.

1.5 Methodik

1.5.1 Anforderungen

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Sie werden im Dokument wie folgt dargestellt:

<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung sämtliche innerhalb der Afo-ID und der Textmarke angeführten Inhalte.

2 Performance-Kenngrößen und ihr Einsatz

Das vorliegende Kapitel definiert die Performance-Kenngrößen für die drei Performance-Dimensionen Bearbeitungszeit, Last und Verfügbarkeit. Außerdem legt es fest, welche Kenngrößen 'reported' werden. 

2.1 Bearbeitungszeit

Bearbeitungszeit bezeichnet die Zeit, welche für die Ausführung einer Funktion, sei es auf Anwendungsfallebene oder auf Ebene einer Operation an den technischen Schnittstellen eines Produkttypen anfällt.

Die auf Ebene der Anwendungsfälle gemessene Bearbeitungszeit, wird der funktionalen Zerlegung und Systemzerlegung des Gesamtsystems folgend, in Bearbeitungszeiten gemessen an den Außenschnittstellen der Produkttypen zerlegt. Dabei kommt es auf eine möglichst exakte und lückenlose Definition der einzelnen Zeitbeiträge an:

• In diesem Dokument wird die Bearbeitungszeit innerhalb der Primärsysteme nicht berücksichtigt.
• Die Bearbeitungszeit innerhalb einer Komponente kann sich aus verschiedenen Bearbeitungszeitbeiträgen zusammensetzen, beispielsweise für einen Request/Reply-Zyklus aus einem Beitrag zum Request und einem zum Reply.
• Jeder Bearbeitungszeitbeitrag innerhalb einer Komponente beginnt, wenn das letzte Bit der Eingangsdaten an die Schnittstelle der Komponente übergeben wurde, und endet, wenn das erste Bit der Ausgangsdaten an der Schnittstelle der Komponente oder des Produktes an das Netzwerk übergeben wird.
• Die einer Netzwerkstrecke zugerechnete Bearbeitungszeit (Übertragungszeit) beginnt, wenn das erste Bit der zu übertragenden Daten an das Netzwerk übergeben wird und endet mit der Übergabe des letzten Bit an die empfangende Komponente.

Die Abarbeitung eines Funktionsaufrufs kann durch die Parallelisierung von Teilschritten beschleunigt werden. Die Verarbeitungszeit entlang des Pfades durch die Teilschritte mit der längsten Bearbeitungszeit (kritischer Pfad) bestimmt die Gesamtbearbeitungszeit.

Die Performance-Dimension Bearbeitungszeit wird idealisiert durch folgende Größen für jeden einzelnen Anwendungsfallaufruf ermittelt:

• Angabe der aufgerufenen Funktion (auf oberster Ebene: Anwendungsfall),
• Zeitpunkt des Ausführungsstarts,
• Bearbeitungszeit,
• für die Bearbeitungszeit verantwortliches Produkt,
• rekursive Zerlegung entlang des kritischen Pfades in weitere Funktionen.

Die Bearbeitungszeiten für einen Anwendungsfall sind nicht für jeden Aufruf gleich. Zum einen können die ausführenden Produkte von Fall zu Fall unterschiedlich sein (z. B. verschiedene Karten), zum anderen wird die Antwortzeit jedes einzelnen Produkts variieren, oft abhängig von zufälligen Situationsparametern.

So kommt es zu einer Verteilung von Bearbeitungszeiten. Im Modell der Bearbeitungszeiten wird diese Verteilung auf zwei statistische Größen reduziert:

• Bearbeitungszeiterwartungswert
• Bearbeitungszeitvarianz

Beide Größen addieren sich für unabhängige Teilschritte unabhängig von der Verteilungsfunktion der Antwortzeiten pro Teilschritt (siehe [UnabhZufall]). Unter der Näherung einer Gaußverteilung der Antwortzeiten lässt sich die Varianz in ein p-Quantil übersetzt, dass sich selbst nicht für einzelne Teilschritte addiert.

Die Zerlegung einer Funktion in Teilfunktionen und die Nutzung der Modellgrößen und illustriert Abbildung 1.

Abbildung 1: Beispiel für Zerlegung einer Funktion und die Modell-Bearbeitungszeitgrößen

Bei Messungen korrespondiert der Erwartungswert des Modells mit dem arithmetischen Mittelwert der Bearbeitungszeiten¹ über eine Gesamtheit von N Einzelmessungen. Er berechnet sich als Summe der Bearbeitungszeiten geteilt durch die Anzahl N der Einzelmessungen.

¹⁾ Mittelwert steht hier ausschließlich für den arithmetischen Mittelwert.

Als Performancevorgaben hinsichtlich Bearbeitungszeit werden für eine definierte Umgebung zwei Schranken vorgegeben:

• Mittelwertschranke für den Bearbeitungszeitmittelwert²
• Quantilschranke für das 99%-Quantil der Bearbeitungszeit

²⁾ Vereinfachend in der Bezeichnung werden Erwartungswert des Modells und arithmetischer Mittelwert der Messungen gleichermaßen mit bezeichnet.

Für eine Gesamtheit von 100 Einzelmessungen darf der Mittelwert der Bearbeitungszeiten nicht größer als die zugehörige Schranke sein und die 99 niedrigsten Bearbeitungszeiten dürfen nicht größer als die Quantilschranke sein.

Für die Produkttypen der zentralen Zone der TI-Plattform müssen Bearbeitungszeitvorgaben unter Last erfüllt werden. Da dabei nicht immer ein Stichprobenumfang von genau 100 Einzelmessungen pro Operation realisiert werden kann, ist es notwendig das gemessene 99%-Quantil für einen allgemeinen Stichprobenumfang der Anzahl n zu definieren.

Quantil-Definition

= Bearbeitungszeit der m-ten Bearbeitungszeit, wobei diese nach aufsteigendem Wert geordnet sind. Dabei ist m[n] = (n – n mod 100) * 0,99 + n mod 100.

Beispiele: m[100] = (100 – 0) * 0,99 + 0 = 99 und m[17] = (17 – 17) * 0,99 + 17 = 17

Inhaltliche Begründung: Ein Ausreißer wird immer nur für volle 100 Aufrufe zugelassen.

2.2 Last

Jede Funktion wird von ihren Nutzern im Betrieb mit einer gewissen Häufigkeit aufgerufen. Die dem Aufruf folgende Verarbeitung innerhalb einer Produktinstanz erzeugt für diese eine Arbeitslast.

Es stellt sich die Frage, wie viele Anfragen parallel von einer Produktinstanz bearbeitet werden müssen. Um dies zu klären, wird zunächst gezeigt, welche Bedeutung der Mittelungszeitraum hat. Auf dieser Grundlage wird dann die Modellierung der Aufrufrate skizziert.

Die Performance-Dimension Last wird idealisiert durch eine Liste der einzelnen Aufrufzeitpunkte repräsentiert .

Abbildung 2 skizziert die Aufrufzeitpunkte für eine Funktion beispielhaft.

Abbildung 2: Beispiel für gemessene Aufrufe, die zu Aufrufzeitpunkten erfolgen

Eine solche exakte Verteilungsfunktion der Aufrufe kann gemittelt werden, indem man zu jedem Zeitpunkt über einen gewissen Zeitraum in der Vergangenheit die Aufrufe zählt und die Anzahl durch den Mittelungszeitraum T teilt. Man erhält so eine Aufrufrate , die auch vom Zeitintervall T abhängt.

Die Abbildung 3 skizziert die Aufrufrate zu der Situation aus Abbildung 2 und identifiziert die höchste Aufrufrate – die „Spitze“ – im Mittelungszeitraum.

Abbildung 3: Beispiel einer über den Zeitraum T gemittelten Aufrufrate

Entspricht der Mittelungszeitraum T der mittleren Antwortzeit, dann gibt eine Spitze die parallel zu bearbeitenden Aufrufe an.

Ein kleinerer Mittelungszeitraum erhöht die Spitzenraten [1/sec] beliebig. Ein größerer Mittelungszeitraum nivelliert die für die Bearbeitung praktisch relevanten, tatsächlich parallel zu verarbeitenden Aufrufzahlen.

Auf Grund dieser Überlegungen wird im Folgenden der Zeitraum T immer gleich der Schranke für den Bearbeitungszeitmittelwert gesetzt. Die Einheit der Aufrufrate kann davon unabhängig für beliebige Zeiteinheiten als [1/Zeiteinheit] angegeben werden, etwa mit [1/sec], [1/h] oder [1/ ].

Modellierung der Aufrufrate

Ziel einer modellhaften Betrachtung der Aufrufrate ist eine möglichst gute Schätzung für die Spitzen in der Aufrufrate . Ausgangspunkt ist die Anzahl der auf einen großen Zeitraum entfallenden Aufrufe, etwa pro T = 1 Jahr = 1y. Anzahl geteilt durch Zeitraum T ergibt die Aufrufrate . Diese Aufrufrate wird bis zu einer Spitzenlast (oder mehreren fallabhängigen Spitzenlasten) entwickelt (Abbildung 4).

Abbildung 4: Entwicklung der Spitzenlast (oder mehreren fallabhängigen Spitzenlasten) aus einer Durchschnittslast pro Jahr.

Die so bestimmte modellierte Spitzenrate hat folgende Bedeutung:

• gibt die im Mittel zu erwartende Anzahl der parallel zu verarbeitenden Aufrufe an,
• die Anzahl der parallelen Aufrufe ist genauer poisson-verteilt, d. h. die Wahrscheinlichkeit für k parallele Aufrufe zu einem Zeitpunkt ist

• Die Wahrscheinlichkeit dafür, dass 2 oder mehr Aufrufe parallel verarbeitet werden müssen ist dann

Die Aufrufrate wird ausgehend von einem auf ein Jahr bezogenen Mengengerüst, unter Berücksichtigung aller verfügbaren Informationen über das Benutzerverhalten, auf eine (oder mehrere fallbezogene) Spitzenlasten entwickelt. Diese Spitzenlast beschreibt für den jeweiligen Spitzenlastzeitraum zufällig verteilte Anfragen. Der zeitliche Abstand der Anfragen ist exponentialverteilt und ihre Häufigkeit für ein Zeitintervall poisson-verteilt. Wird als Zeitintervall die erwartete Bearbeitungszeit gewählt, ist durch diese Poisson-Verteilung die Anzahl der parallel zu bearbeitenden Anfragen beschrieben.

Lastbegriff

Durch zwei Anforderungen wird gewährleistet, dass Aufrufe auch erwartungsgemäß bearbeitet werden:

Für jeden Produkttyp der TI-Plattform wird gefordert, dass die an seinen Außenschnittstellen angebotenen Operationen, bei der maximal erwarteten Aufrufrate für diese Schnittstelle funktional korrekt bearbeitet werden. Beispiel für eine solche reine Durchsatzanforderung ist die Anforderung an die Störungsampel.

Sollte es vorkommen, dass die gemäß Spitzenlast maximal erwartete Aufrufrate überschritten wird, muss sich die TI-Plattform stabil verhalten, was durch die Anforderung [GS-A_4145] für Produkttypen der zentralen Zone der TI-Plattform sichergestellt wird.

Im Folgenden verwendete Lastbegriffe:

• Last – Anzahl von Aufrufen einer bestimmten Funktionalität pro Zeiteinheit.
• Lastspitze – Die im Betrieb tatsächlich auftretende Maximallast pro Sekunde für eine definierte Funktionalität.
• Spitzenlast – Die von allen Produktinstanzen eines Produkttyps für eine definierte Funktionalität gemeinsam zu bewältigende Last.

2.3 Verfügbarkeit

Folgende Begriffe werden definiert:

• Ausfall – Ein System gilt für den Erfassungszeitraum als ausgefallen, wenn im Erfassungszeitraum 20% oder mehr der Anfragen nicht erfolgreich verarbeitet werden. Gemäß [GS-A_4146] besteht der Erfassungszeitraum aus 5 Minuten.
  Die zeitnahe Feststellung von Start- und den Endzeitpunkt jedes Ausfalls regeln die Anforderungen in Kapitel 2.4.

Abweichend gilt für die Fachdienste VSDM (UFS, VSDD, CMS), dass ein Ausfall vorliegt, wenn der Fachdienst nicht zur Verfügung steht. Der Ausfall der definierten funktionalen Eigenschaften der Fachdienste VSDM wird durch das Service Monitoring ermittelt. 

• Verfügbarkeit – Die Verfügbarkeit eines Produkttyps wird unterteilt in Verfügbarkeit funktionaler und nicht-funktionaler Eigenschaften. Die Verfügbarkeit funktionaler Eigenschaften eines Produkttyps wird u.a. durch das Service Monitoring überwacht (fachliche Anfrage an den Dienst durch Probes und Interpretation der Antwort/des Ergebnisses). Der Begriff Verfügbarkeit bezeichnet im Folgenden die Verfügbarkeit der funktionalen Eigenschaften, sofern nicht anders ausgeführt.
  
  Die Verfügbarkeit wird in diesem Dokument als (Gesamtzeit – Gesamtausfallzeit)/Gesamtzeit berechnet. Die Gesamtausfallzeit setzt sich aus der Summe der Erfassungszeiträume zusammen, in denen das System ausgefallen ist.
• Längste Ausfalldauer - ist die längste Ausfalldauer am Stück.
• Hauptzeit – Zeitfenster in dem eine hohe Last zu erwarten ist.
• Nebenzeit – Zeitfenster in dem eine niedrige Last zu erwarten ist.

Die Performance-Dimension Verfügbarkeit wird über die Gesamtzeit und die Dauer der konkreten  Ausfälle berechnet. Dabei ist ein konkretes Zeitintervall durch einen konkreten Startzeitpunkt und einen konkreten Endzeitpunkt beschrieben (z. B.: 17.08.2015 16:35:00 bis 17.08.2015 16:40:00). Wenn nicht ein gesamter Dienst ausgefallen ist, muss zusätzlich noch erfasst werden, auf welche Schnittstellenoperationen oder Verbindungen im Falle des zentralen Netzes sich der Ausfall bezieht. Da Ausfälle grundsätzlich selten erfolgen dürfen, besteht kein Bedarf diese Messdaten für ein etwaiges Reporting vor der Lieferung zu aggregieren.

Aggregierte Sicht auf Verfügbarkeiten

Um die Verfügbarkeit der TI für einen Anwendungsfall zu bestimmen, muss die Verfügbarkeit aller für die Bearbeitung einer Anfrage notwendigen Produkttypen berücksichtigt werden. Genauer müssen die konkreten Zeitintervalle aller Ausfälle berücksichtigt werden.

Zwei Extremfälle können auftreten:

• Keines der konkreten Zeitintervalle überlappt mit einem anderen. Dann sind die Produkttypen in diesem Fall bezüglich der Verfügbarkeiten unabhängig und die Verfügbarkeiten können multipliziert werden.
• Alle konkreten Zeitintervalle sind identisch – etwa, weil es sich um ein gut koordiniertes Wartungsfenster handelt. In diesem Fall ist die Gesamtverfügbarkeit gleich der jeder einzelnen Produktinstanz.

Der erste Fall wird im Folgenden vereinfachend für die Modellierung der Verfügbarkeit angenommen. Der zweite Fall muss vom Betrieb berücksichtigt werden, weil hier durch Koordination von Ausfallzeitintervallen bei fixer Verfügbarkeit von Einzelkomponenten die Ende-zu-Ende-Verfügbarkeit für Anwendungsfälle gesteigert werden kann.

Caching

Der positive Effekt des Cachings auf die Verfügbarkeit von Anwendungsfällen ist tageszeitabhängig. Beim Stellen von Verfügbarkeitsanforderungen an die Produkttypen wird der Caching-Effekt daher nicht berücksichtigt.

Toleranzschranken für längste Ausfalldauer und Verfügbarkeit

Toleranzschranken für die Verfügbarkeit in Prozent und die längste Ausfalldauer bilden die zu definierenden Verfügbarkeitsanforderungen. Mit der Angabe eines Bezugszeitraumes (Monat oder Jahr) kann die Vorgabe einer Toleranzschranke für die längste Ausfalldauer entfallen, wenn die tolerierte Gesamtausfallzeit im Bezugszeitraum unterhalb der Toleranzschranke für die längste Ausfalldauer liegt.

2.4 Einsatz der Performance-Kenngrößen

Die Performance-Betrachtung dient dem Ziel, die benötigte und erwartete Leistung in Bezug auf die Performance-Dimensionen „Bearbeitungszeit, Last und Verfügbarkeit “ für die Anwendungsfälle dauerhaft im Betrieb zur Verfügung zu stellen.

Um dies zu erreichen, werden zum einen Blattanforderungen für das Bearbeitungszeitverhalten von Operationen an den Außenschnittstellen der Produkttypen gestellt. Dabei wird auch festgelegt unter welcher Last diese Vorgaben zu erfüllen sind. Diese sind zulassungsrelevant. Zum anderen werden Performance-Daten im Betrieb erfasst, die eine Rückkopplung auf verschiedenen Ebenen erlauben:

• Über die Störungsampel bzw. zukünftig über das Service Monitoring wird der aktuelle Zustand der TI reflektiert.
• Performance-Reports fließen zurück ins Performance-Modell, das dadurch nachjustiert werden kann.
• SLA-Reports zeigen, ob bestehende Service-Vereinbarungen eingehalten werden und ob die bestehenden ausreichend sind, den Bedarf zu erfüllen.

Hinweise:

• Dass Messverfahren zur Ermittlung eines Ausfalls wird nicht vorgegeben. Es wird erwartet, dass hier in Abhängigkeit von den Ausfallszenarien geeignete Verfahren gewählt werden.
• Bei der Definition des „Start/Endzeitpunkt eines Ausfalls“ ist die konkrete Implementierung des Messverfahrens unerheblich. Es geht nur um die prinzipielle Erkennbarkeit.
• Für die Feststellung eines Ausfalls muss nicht notwendigerweise in allen Ausfallszenarien eine Gesamtheit von Anfragen analysiert werden.
• Bei einem Komplettausfall eines Produkttyps der zentralen Zone der TI-Plattform bzw. des VSDM Intermediärs einschl. deren Systembestandteilen zur Überwachung des Systems kann keine Meldung des Ausfalls als Ereignisnachricht im Sinne von GS-A_4148 erfolgen.

Performance-Reporting-Daten

Die Performance-Reporting-Daten werden von den Anbietern an die gematik übermittelt, um eine Aussage über den aktuellen Zustand der TI zu ermöglichen.  Es wird produkttypübergreifend festgelegt, welche Performance-Reporting-Daten in jedem Erfassungsintervall erfasst werden müssen.

Last:

• Anzahl der Aufrufe im Reporting-Intervall
• Anzahl der fehlerfrei bearbeiteten Aufrufe

Bearbeitungszeit (jeweils pro Schnittstellenoperation)

• Anzahl der summierten Bearbeitungszeiten
• Summe der Bearbeitungszeiten
• Anzahl der Bearbeitungszeiten größer als die 99%-Quantilschranke.

Verfügbarkeit (jeweils pro Schnittstellenoperation)

• alle Ausfälle mit Angabe des konkreten Ausfallzeitintervalls
  (pro Produkttyp, wenn der gesamte Produkttyp betroffen ist, und pro Schnittstellenoperation, wenn nur einzelne Schnittstellenoperationen betroffen sind)

Produkttypspezifisch sind die Operationen und gegebenenfalls weitere Parameter nach denen ein Aufriss der Bearbeitungszeiten erfolgt. Ein etwaiger weiterer Aufriss (etwa nach Verbindungen von Produkttyp zu Produkttyp beim zentralen Netz) erfolgt ebenfalls produkttypspezifisch.

Relevanz für Service Level Agreements

Service Level Agreements (SLA) bzgl. Performance-Vorgaben werden für alle Produkttypen der zentralen Zone der TI-Plattform vereinbart.

Die Prozesse zum Service Level Management legen die Richtlinien zum Betrieb [gemRL_Betr_TI] fest. Sie beinhalten Anforderungen zum Service Level Reporting.

Welche Performance-Kenngrößen in den Service Level Reports aufgenommen werden, legt die Spalte „Service Level Report“ in Tabelle "Tab_gemKPT_Betr_Performance-Kenngroessen" in [gemKPT_Betr] fest.

Die konkreten Leistungsanforderungen pro Produkttyp stellt Kapitel 4 dar.

Für die Auswertung der Bearbeitungszeiten wird geprüft, ob die Mittelwertschranke bezogen auf den Monatszeitraum eingehalten wird. Zur Überprüfung der 99%-Quantilvorgaben wird geprüft, ob die Anzahl der Antwortzeiten größer der vorgegebenen 99%-Quantilschranke kleiner gleich 1 % der Gesamtanfragen ist.

Wenn nicht explizit angegeben, ist die maximale Ausfalldauer für SLAs als
(1 – Verfügbarkeit) * 1 Monat anzusetzen.

Sind die Verfügbarkeitsanforderungen pro Produkttyp definiert, so müssen sie durch jede von ihm angebotene Schnittstellenoperation für sich erfüllt werden. Die hierfür maßgeblichen Schnittstellenoperationen gibt Tabelle  "Tab_gemKPT_Betr_Performance-Kenngroessen" in [gemKPT_Betr] vor. Ein Produkttyp erfüllt die Verfügbarkeitsanforderungen, wenn alle von ihm angebotenen Schnittstellenoperationen die Verfügbarkeitsanforderungen erfüllen.

Die Lastangaben gelten, soweit nicht explizit abweichend angegeben, jeweils für alle Instanzen eines Produkttypen in Summe.

2.5 Performance-Evaluierung auf der Basis von Rohdaten

Die Rohdaten eines Produkttyps erfassen das Performanceverhalten von Diensten der TI. Diese Rohdaten beinhalten folgende Informationen:

• Zeitpunkt des Aufrufs
• Bearbeitungszeit des Aufrufes
• aufgerufene Operation
• Erfolg der Operationsbearbeitung
• weitere produkttypspezifische und operationsspezifische Informationen

Aus den Rohdaten lassen sich die Performance-Kenngrößen (z.B. die Abbruchquote als Anteil der nicht erfolgreich verarbeiteten Aufrufe gemessen an der Anzahl der Aufrufe) für den Produkttyp ermitteln und auf deren Basis die Einhaltung der Service Level bestimmen. 

Dazu erfassen Produkttypen die Rohdaten und stellen sie der Betriebsdatenerfassung in dem hier festgelegten Performance-Berichtsformat zur Verfügung.

2.5.1 Rohdaten-Performance-Reporting (Rohdatenerfassung v.01)

Im Folgenden ist das Berichtsformat in der Version v.01 beschrieben. Produkttypen, welche auf diese Version verpflichtet sind, werden im Laufe der Zeit auf die aktuellste Version angehoben. Neuzulassungen sind auf die Version v.01 nicht mehr möglich.

Ein Beispiel für zwei Einträge, der erste zu einem fehlerfreien Aufruf, der zweite zu einem Aufruf, der nicht fehlerfrei durchlaufen wurde:

INFO: start[1000212390109] time[447] tag[UFS.GetUpdateFlags]
INFO: start[1000212470109] time[2]   tag[UFS.GetUpdateFlags.failed]

Hinweis:

Unter einer fehlerhaften Operation wird verstanden, wenn die Operation z.B. selbst fehlerhaft abgebrochen wurde bzw. nicht oder zu spät beantwortet wurde. Eine Antwort auf ein nicht vorhandenes Datum (ICCSN, Seriennummer etc.) ist eine fehlerfreie Operation und nicht mit ".failed" zu kennzeichnen.

Hinweis: Ein CI (Configuration Item) kann auch ein Knoten oder ein Standort sein.

2.5.2 Rohdaten-Performance-Reporting (Rohdatenerfassung v.02)

Die Version v.02 der Rohdatenerfassung ersetzt die bisher zulassungsfähige Version v.01 und ist im Folgenden näher definiert. Neuzulassungen oder Änderungszulassungen sind nur auf Basis der Rohdatenerfassung v.02 möglich.

Tab_gemSpec_Perf_Produkte_Rohdatenerfassung_Version_v02 gibt einen Überblick über die Produkttypen, welche bereits Rohdaten-Performance-Berichte in der Version v.02 übermitteln, bzw. sich aktuell in der Umstellung befinden.

Tabelle 1 : Tab_gemSpec_Perf_Produkte_Rohdatenerfassung_Version_v02

2.5.2.1 Umfang

(Hinweis: Für weitere Informationen zum CI, siehe [gemRL_Betr_TI] Kapitel "Configuration Management".)

"Intervalltreu" bedeutet hierbei: Jeder Eintrag muss in dem Rohdaten-Performance-Bericht gesendet werden, in dessen Berichtsintervall sein Endezeitpunkt $timestamp + $duration_in_ms liegt.

Die Nachlieferung hat dabei in der gleichen Art wie die Originallieferung zu erfolgen (keine Zusammenfassung mehrerer Rohdaten-Nachlieferungen). Bei mehreren Nachlieferungen sind die Einzellieferungen separat und zeitlich gestaffelt zwischen den Standardlieferungen zu tätigen (z.B. bei einem 5-Minuten-Intervall nach 2,5 Minuten EINE Nachlieferung und nach 5 Minuten dann die Standardlieferung).

Die vorgeschriebenen Aufbewahrungspflichten bleiben hiervon unberührt. Umfang und Details zur Nachlieferung bzgl. Nachlieferungszeitpunkt und Zusammenfassung sind mit dem Gesamtverantwortlichen TI abzustimmen.

2.5.2.2 Lieferintervalle

Die Anpassung der Lieferintervalle ist im Rahmen des TI-ITSM durch das Changemanagement zu prozessieren.

2.5.2.3 Format

Hinweis: Es sind die konkreten HTTP-Statuscodes zu verwenden und die "xx" entsprechend zu ersetzen.

Zwei beispielhafte Einträge eines Beispielproduktes und einer dazugehörigen Beispieloperation:

I:   1000212390109;447;Beispielprodukt.Beispieloperation;200;{"ID":12}

II:  1000212470109;12;Beispielprodukt.Beispieloperation;40001;{"ID":12,"Antwort":"gesperrt"}

3 Produkttypspezifische Vorgaben

Die produkttypspezifischen Vorgaben dieses Kapitels ergänzen die allgemeinen Anforderungen der Rohdatenerfassung für jeden Produkttypen zusammengefasst und übersichtlich.

3.1 IDP-Dienste

3.1.1 Leistungsanforderungen IDP-Dienste

3.1.1.1 Lastmodell IDP-Dienste

Die Tokenbasierte Authentisierung umfasst folgende performance-relevanten Operationen:

• I_IDP_Auth_Active_Client
• • issue_Identity_Assertion
  • renew_Identity_Assertion
  • cancel_Identity_Assertion
• I_IDP_Auth_Passive_Client
• • signin
  • signout
• I_Local_IDP_Service
• • sign_Token

[Weiteres im Folgekapitel "Performancevorgaben IDP-Dienste" enthalten]

3.1.1.2 Bearbeitungszeiten IDP-Dienste

Für die Tokenbasierte Authentisierung müssen unter den oben genannten Rahmenbedingungen die Mittelwerte der Bearbeitungszeiten pro Anwendungsfall kleiner oder gleich den in Tabelle "Tab_Bearbeitungszeitvorgaben Tokenbasierte Authentisierung je Anwendungsfall" angegebenen Mittelwertschranken sein.

Tabelle 3: Tab_Bearbeitungszeitvorgaben Tokenbasierte Authentisierung je Anwendungsfall

3.1.1.3 Performancevorgaben IDP-Dienste

Hinweis:

Die Duration für IDP.UC_20 beginnt mit der Annahme des Authorization Request am Authorization-Endpunkt und endet mit der Herausgabe des Authorization_Code.
Die Duration für  IDP.UC_21 beginnt mit der Annahme des Token Request am Token-Endpunkt und endet mit der Herausgabe des Token.

Hinweis: Alle Anfragen, die bei einer Lastspitze über die gemäß der definierten Spitzenlasten zu verarbeitenden Anzahl von Anfragen hinausgehen, kann der Dienst vorübergehend abweisen. Dabei müssen die definierten Spitzenlasten weiterhin innerhalb der Performancevorgaben verarbeitet werden. Vom System angenommene Anfragen müssen weiterhin innerhalb der Performancevorgaben verarbeitet werden. Der Betreiber des Fachdienstes hat seinen Produktbetrieb auf die neuen, höheren Lastspitzen zu skalieren.

Hinweis: Die potentiellen Gesamtnutzerzahlen je Sektor können bei den Standesorganisationen oder der gematik erfragt werden.

Im Zuge des Zulassungsverfahrens hat der Betreiber des IdP-Dienst der gematik gegenüber nachvollziehbar darzustellen, welche technischen Skalierungsmaßnahmen anhand welcher messbarer Parameter er für den Produktivbetrieb plant durchzuführen. Die Skalierungsmaßnahmen können dabei unterschiedliche Ausprägungen und Dimensionen umfassen. Beispielsweise eine automatisierte Ressourcenzuteilung oder eine Anpassung oder Änderung unterschiedlicher technischer Komponenten, die zu einer Produktänderung im Sinne der [gemSpec_OM] führt. Die Darstellung muss Verifikationsbeschreibungen enthalten, mit denen der Erfolg der Maßnahmen ermittelt werden kann.

3.1.2 Rohdaten-Performance-Reporting Spezifika IDP-Dienste

In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produkttypspezifischen Anforderungen.

3.1.2.1 Spezifika Umfang IDP-Dienste

3.1.2.2 Spezifika Format IDP-Dienste

Abbrüche des Anwendungsfalls können so differenziert erfasst werden. In den Fällen, bei denen die OCSP-Anfrage des zuständigen TSP zu spät beantwortet wird, erfolgt eine gesonderte Markierung in den Rohdaten. Dies ist notwendig zur Errechnung der Performancevorgaben des IDP. Hierbei werden diese Abbrüche nicht dem IDP angelastet.

3.1.3 Bestandsdaten sektoraler IDP

3.2 E-Rezept

3.2.1 Leistungsanforderungen E-Rezept

3.2.1.1 Lastmodell E-Rezept

Die Anwendungsfälle zum E-Rezept setzen den Workflow der Verordnung von apothekenpflichtigen Arzneimitteln um. Dabei werden die folgenden performance-relevanten Anwendungsfälle gemäß [gemSpec_FD_eRp] betrachtet:

• E-Rezept durch Verordnenden erzeugen und einstellen
  
• E-Rezept durch Abgebenden abrufen
• Nachricht durch Abgebenden übermitteln/empfangen
• Abgabe durch Abgebenden vollziehen
• E-Rezept durch Versicherten abrufen
• Nachricht durch Versicherten übermitteln/empfangen

Bei jedem der genannten UseCases wird von einer existierenden, authentifizierten Nutzer-Session ausgegangen. Die jeweils übertragene Datenmenge hängt von der Anzahl der transportierten E-Rezepte ab. Je Anwendungsfall wird von einer Datenmenge von 10 kByte ausgegangen.

Die Tabelle "Tab_Lastmodell E-Rezept aus der LE-U für Praxen, Apotheken und Versicherte" stellt eine Übersicht über die zu erwartenden Nutzungsraten für das E-Rezept dar. In der Lastbetrachtung wird von 4,8 Mio. ausgestellten und 3,7 Mio eingelöste Verordnungszeilen pro Tag ausgegangen. Das entspricht dem höchsten Aufkommen von Rezepten an einem Tag im Jahre 2018. Ebenfalls wird je Patient mit 1,4 Verordnungen (gerundet auf 2) kalkuliert.

Tabelle 11: Tab_Lastmodell E-Rezept aus der LE-U für Praxen, Apotheken und Versicherte

Zur Ermittlung der Last in der (Zahn-)Arztpraxis/Krankenhaus wird die Anzahl der verordnenden Leistungserbringer zugrunde gelegt, da für die Verordnung zwingend ein Heilberufsausweis für die QES benötigt wird und ebenso nur Ärzte/Zahnärzte zur Verordnung von Medikamenten berechtigt sind.

Der Vollzug der Abgabe durch den Abgebenden erfordert eine weitere Signatur durch einen Heilberufler bzw. in besonderen Fällen eine QES durch den Apotheker, weshalb hier M25 anstelle von M27 betrachtet wird.

In der Kommunikation zwischen Apotheken und Versicherten zur Abfrage der Verfügbarkeit von Medikamenten wird von einer Nutzungsrate von 30% ausgegangen.

3.2.1.2 Bearbeitungszeiten E-Rezept

Für das E-Rezept müssen unter den oben genannten Rahmenbedingungen die Mittelwerte der Bearbeitungszeiten pro Anwendungsfall kleiner oder gleich den in Tabelle "Tab_eRp Bearbeitungszeitvorgaben je Anwendungsfall" angegebenen Mittelwerten sein.

Tabelle 12: Tab_eRp Bearbeitungszeitvorgaben je Anwendungsfall

Die ID aus der Tabelle "Tab_gemSpec_Perf_eRP-Fachdienst: Last- und Bearbeitungszeitvorgaben" referenziert auf den entsprechenden Anwendungsfall gemäß [gemSysL_eRp].

Die erhöhte Bearbeitungszeit bei den Anwendungsfällen zur Erstellung eines E-Rezepts beim Verordnenden und dem Abruf eines Rezeptes beim Abgebenden sind daraus zu begründen, dass hier die Konnektor-Operationen für das QES-Signieren und QES-Verifizieren von 10 KB-Dokumenten enthalten sind.

Ebenfalls ist die erhöhte Bearbeitungszeit daraus zu begründen, dass ist in der Modellbetrachtung von einer Transportanbindung von 1024 kbit/sec in Download-Richtung und 128 kbit/sec in Upload-Richtung für die Leistungserbringer-Umgebung sowie für die des Versicherten ausgegangen wird.

(*) In der Bearbeitungszeit wird mit dem aktuellen Referenzwert für die QES-Erstellung gerechnet, da noch keine Aussage zur Bearbeitungsdauer der QES-Erstellung mittels Komfortsignatur getroffen werden kann.

Hinweis: In den Bearbeitungszeitvorgaben der jeweiligen Anwendungsfällen ist die Ausstellung der ID-Tokens des Identity Providers nicht berücksichtigt.

3.2.1.3 Performancevorgaben E-Rezept

Die ID aus der Tabelle "Tab_gemSpec_Perf_eRP-Fachdienst: Last- und Bearbeitungszeitvorgaben" referenziert auf den entsprechenden Anwendungsfall gemäß [gemSysL_eRp]. Die in der Tabelle definierten Bearbeitungszeiten beziehen sich auf die vom Fachdienst umzusetzenden Operationen in den referenzierten Anwendungsfällen.

Hinweis: Alle Anfragen, die bei einer Lastspitze über die gemäß der definierten Spitzenlasten zu verarbeitenden Anzahl von Anfragen hinausgehen, kann der E-Rezept-Fachdienst vorübergehend abweisen. Dabei müssen die definierten Spitzenlasten weiterhin innerhalb der Performancevorgaben verarbeitet werden. Vom System angenommene Anfragen müssen weiterhin innerhalb der Performancevorgaben verarbeitet werden. Der Anbieter des Fachdienstes hat seinen Produktbetrieb auf die neuen, höheren Lastspitzen zu skalieren.

Im Zuge des Zulassungsverfahrens hat der Anbieter des E-Rezept-Fachdienstes der gematik gegenüber nachvollziehbar darzustellen, welche technischen Skalierungsmaßnahmen anhand welcher messbarer Parameter er für den Produktivbetrieb plant durchzuführen. Die Skalierungsmaßnahmen können dabei unterschiedliche Ausprägungen und Dimensionen umfassen. Beispielsweise eine automatisierte Ressourcenzuteilung oder eine Anpassung oder Änderung unterschiedlicher technischer Komponenten, die zu einer Produktänderung im Sinne der [gemSpec_OM] führt. Die Darstellung muss Verifikationsbeschreibungen enthalten, mit denen der Erfolg der Maßnahmen ermittelt werden kann.

Die Verfügbarkeit der funktionalen Eigenschaften des E-Rezept-Fachdienstes wird mittels der Probes des Service Monitorings und die nicht funktionalen Eigenschaften durch Auswertung der Rohdaten ermittelt.

3.2.2 Rohdaten-Performance-Reporting Spezifika E-Rezept

In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produktspezifischen Anforderungen.

3.2.2.1 Umfang

3.2.2.2 Format

Tabelle 14 Tab_gemSpec_Perf_Berichtsformat_E-Rezept-Fachdienst

3.2.3 Bestandsdaten

Da bei dieser Lieferung keine Datei übermittelt wird, sondern der Text direkt im Body, ist für diese Lieferung die Angabe des filenames im HTTP-Header gemäß [A_17733-01] (Tabelle: Tab_I_OpsData_Update_002 Operation I_OpsData_Update::fileUpload) in der gemSpec_SST_LD_BD NICHT notwendig.

3.3 TI-Messenger (TI-M)

Dieses Kapitel dient der Ergänzung der TI-Messenger (TI-M) Spezifikationen [gemSpec_TI-Messenger-Dienst], [gemSpec_TI-Messenger-FD] und [gemSpec_TI-Messenger-Client]. Der gesamte Anforderungshaushalt inkl. Referenzen auf weitere normative Dokumente an die jeweiligen TI-M Produkte und Anbieter findet sich in diesen Dokumenten als auch in den entsprechenden Produkt- bzw. Anbietertypsteckbriefen.

3.3.1 Verfügbarkeit

3.3.2 Rohdaten

*1) Hinweis: Die Beschreibung entspricht dem Ende eines erfolgreichen Anwendungsfalls. Wenn der Anwendungsfall abbricht und/oder eine Fehlermeldung erzeugt, so MUSS im JSON-message-Block für das Feld httpStatus der negative http-Statuscode entsprechend der Beschreibung im Anwendungsfall eingetragen werden. Für jede Anwendungsfall-Instanz MUSS eine eindeutige ID vergeben werden. Die ID KANN mit einem Abstand von 6 Monaten neu vergeben werden um die Operationen innerhalb eines Anwendungsfalls konsolidieren zu können und gleichzeitig von anderen Anwendungsfall-Instanzen abzugrenzen.

Bestandsdaten

3.4 TSP X.509

Im folgenden werden die spezifischen Leistungsanforderungen und Anforderungen an das Rohdaten-Performance-Berichtsformat der TSP X.509 aufgeführt.

3.4.1 Leistungsanforderungen TSP X.509

3.4.1.1 Lastmodell TSP X.509

[Das Verschieben der Vorgaben im Rahmen der Umstrukturierung des Dokumentes erfolgt im Nachgang]

[Die Vorgaben befinden sich aktuell im Kapitel ]

3.4.1.2 Bearbeitungszeiten TSP X.509

[Das Verschieben der Vorgaben im Rahmen der Umstrukturierung des Dokumentes erfolgt im Nachgang]

3.4.1.3 Performancevorgaben TSP X.509

[Das Verschieben der Vorgaben im Rahmen der Umstrukturierung des Dokumentes erfolgt im Nachgang]

[Die Vorgaben befinden sich aktuell in den Kapiteln  und ]

3.4.2 Rohdaten-Performance-Reporting Spezifika TSP X.509

In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produktspezifischen Anforderungen.

3.4.2.1 Umfang

keine Spezifischen Anforderungen zum Umfang

3.4.2.2 Format

Tabelle 15: Tab_gemSpec_Perf_Berichtsformat_TSP-X.509

3.5 IDP-Federation Master

3.5.1 Leistungsanforderungen IDP-Federation Master

3.5.1.1 Lastmodell IDP-Federation Master

3.5.1.2 Bearbeitungszeiten IDP-Federation Master

3.5.1.3 Performancevorgaben IDP-Federation Master

3.5.2 Rohdaten-Performance-Reporting Spezifika IDP-Federation Master

In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produkttypspezifischen Anforderungen.

3.5.2.1 Spezifika Umfang IDP-Federation Master

3.5.2.2 Spezifika Format IDP-Federation Master

3.6 VPN-Zugangsdienst

Der Produkttyp VPN-Zugangsdienst verbindet Transportnetz und Zentrales Netz der TI. Für OCSP-Request sorgt er dabei für ein http-Forwarding.

Zusätzlich zu dieser über die Schnittstelle I_Secure_Channel_Tunnel angebotenen Leistung, bietet der VPN-Zugangsdienst Leistungen über die Schnittstellen I_DNS_Name_Resolution und I_NTP_Time_Information an.

3.6.1 Leistungsanforderungen VPN-Zugangsdienst

3.6.1.1 Lastmodell VPN-Zugangsdienst

keine Spezifischen Anforderungen zum Lastmodell

3.6.1.2 Bearbeitungszeiten VPN-Zugangsdienst

Für die Schnittstelle I_DNS_Name_Resolution gelten die Anforderungen wie für den Namensdienst:

Für die Schnittstelle I_Secure_Channel_Tunnel gelten die folgenden Anforderungen:

3.6.1.3 Performancevorgaben VPN-Zugangsdienst

Für die Schnittstelle I_DNS_Name_Resolution gelten die Anforderungen wie für den Namensdienst:

Für die Schnittstelle I_NTP_Time_Information gelten die Anforderungen wie für den Zeitdienst:

Für die Schnittstelle I_Secure_Channel_Tunnel gelten die folgenden Anforderungen:

Die Anforderung [] verlangt eine Verfügbarkeit, die sowohl die primäre Leistung der Verbindung von Transportnetz und Zentralem Netz der TI mit Terminierung des VPN-Kanals beinhaltet, also auch DNS-Anfragen und http-Forwarding. Nicht inkludiert in der Verfügbarkeit ist wegen ihres asynchronen Beitrags zu Anwendungsfällen die NTP-Schnittstelle.

Wie die Volumenmessungen zu erfolgen hat, regelt die nachfolgende Anforderung, siehe hierzu [gemKPT_Arch_TIP], Abbildung „Netzwerktopologie der TI“:

Weitere Anforderungen:

3.6.2 Rohdaten-Performance-Reporting Spezifika VPN-Zugangsdienst

In Ergänzung an die allgemeinen Anforderungen an das Performance-Rohdaten-Reporting befinden sich nachfolgend die produktspezifischen Anforderungen.

3.6.2.1 Umfang

keine Spezifischen Anforderungen zum Umfang

3.6.2.2 Format

Tabelle #: Tab_gemSpec_Perf_Berichtsformat_VPN-ZugD

4 Leistungsanforderungen für Anwendungsfälle

Das vorliegende Kapitel erfasst die Leistungsanforderungen aus den Anwendungen der TI im Wirkbetrieb:

• Versichertenstammdaten-Management (VSDM)
• Kommunikation für Leistungserbringer (KOM-LE)
• Notfalldatenmanagement (NFDM)
• eMP/AMTS-Datenmanagement (AMTS)
• elektronische Patientenakte (ePA)
• Tokenbasierte Authentisierung (TBAuth)
• Qualifizierte Elektronische Signatur (QES)
• Digitale Signatur und Verschlüsselung
• Anbindung Bestandsnetze

Die Leistungsanforderungen werden hier der Reihe nach für die drei Performance-Dimensionen Last, Bearbeitungszeit und Verfügbarkeit aufgeführt.

4.1 Spitzenlasten für Anwendungsfälle

Ausgangspunkt für die Modellierung von Spitzenlasten auf Ebene der Anwendungsfälle ist ein Mengengerüst der Leistungserbringer in Praxen und Krankenhäuser sowie den gesetzlich Krankenversicherten und ihren Behandlungsfällen. Spitzenlasten für die Anwendungsfallnutzung berechnet das Lastmodell als Produkt aus Mengengröße und einem Proportionalitätsfaktor, welcher das bekannte und erwartete Benutzerverhalten widerspiegelt.

Der Ansatz über die Proportionalitätsfaktoren erlaubt es, die Spitzenlasten an den jeweiligen Kontext anzupassen: für eine Praxis, für ein Krankenhaus einer bestimmten Größe oder für die TI insgesamt im Produktivbetrieb.

4.1.1 Mengengerüst

Im Folgenden wird das Mengengerüst für den Produktivbetrieb aufgestellt, welches alle gesetzlich Krankenversicherte bedient.

Da letztlich die Leistungen des Gesundheitswesens für die Krankenversicherten erbracht werden, ist die Zahl des Versicherten die zentrale Mengengröße, mit der alle Mengenangaben skalieren. D. h. alle Lastangaben die sich im Folgenden auf alle 70 Mio. Versicherten beziehen, können auf kleinere Mengen heruntergerechnet werden – etwa pro 1 Mio. Versicherten, indem Lastangaben durch 70 geteilt werden.

Die Tabelle "Tab_Mengengerüst: Versicherte und Leistungserbringer" gibt die Zahl der Versicherten, der niedergelassenen Leistungserbringer und der Krankenhäuser an. Es folgt eine Größenklassifizierung der Praxen in Tabelle "Tab_Mengengerüst: Lokationen" sowie der Krankenhäuser in Tabelle "Tab_Mengengerüst: Krankenhäuser". Die Tabelle "Tab_Mengengerüst: Annahmen für Modellierung"  trifft Annahmen zur Modellierung.

Da die Lastbetrachtung große Unwägbarkeiten bzgl. des Benutzerverhaltens enthält, ist eine Signifikanz von 1-2 Stellen in den Zahlen des Mengengerüsts ausreichend. Die Zahlen sind daher entsprechend gerundet und beim Bezugszeitpunkt der Größen wird eine entsprechende Ungenauigkeit zugelassen.

Tabelle 17: Tab_Mengengerüst: Versicherte und Leistungserbringer

Tabelle 18: Tab_Mengengerüst: Lokationen

Tabelle 19: Tab_Mengengerüst: Krankenhäuser (Quelle: [DKG2010])

Tabelle 20: Tab_Mengengerüst: Klassen der Leistungserbringer(LE)-Umgebungen

Tabelle "Tab_Mengengerüst: Klassen der Leistungserbringer(LE)-Umgebungen" nimmt eine grobe Klassifizierung sämtlicher Leistungserbringerumgebungen in vier Größenklassen vor. Klasse LE-U1 beinhaltet Praxen, Gemeinschaftspraxen, medizinische Versorgungszentren und Krankenhäuser bis 199 Betten³. Klasse LE-U2 umfasst Krankenhäuser bis 599 Betten. Klasse LE-U3 umfasst große Krankenhäuser. Klasse LE-U4 umfasst sehr große Krankenhäuser. Im Hinblick auf Lastanforderungen ist für jede Klasse ein besonders großer Repräsentant ausgewählt. Der Repräsentant der Klasse 4 wurde so groß gewählt, dass er mit Sicherheit größer als die größten existierenden Krankenhäuser ist.

³⁾ Perspektivisch kann es in späteren Ausrollstufen entsprechend des Lastaufkommens für weitere Anwendungsfälle notwendig werden, die Klasse weiter zu unterteilen. Neben dem Klassenrepräsentanten eines "100 bis 199 Betten"-Krankenhaus wird zusätzlich als Praxisrepräsentant eine Praxis für 1000 Versicherte berücksichtigt. Die jeweils pro Anwendungsfall höheren Spitzenlasten dieser beiden Repräsentanten sind für die Anforderungen maßgeblich.

Tabelle 21: Tab_Mengengerüst: Annahmen für Modellierung

4.1.2 Versichertenstammdatenmanagement (VSDM)

Das Versichertenstammdatenmanagement (VSDM) umfasst fünf performance-relevante Anwendungsfälle (siehe [gemKPT_Perf_VSDM]), die eine Kombination der folgenden drei Aktivitäten gemäß Tabelle "Tab_VSDM Anwendungsfälle" sind:

• Abfrage, ob eine Aktualisierung der Versichertenstammdaten (VSD) vorliegt,
• Aktualisierung der VSD auf der eGK, falls eine Aktualisierung vorliegt,
• Lesen der VSD von der eGK.

Tabelle 22: Tab_VSDM Anwendungsfälle

In der folgenden Lastbetrachtung wird vereinfachend davon ausgegangen, dass nur das Online-Szenario genutzt wird, das die Anwendungsfälle 1 und 2 umfasst. Zusätzlich wird angenommen, dass bei jedem „Lesen VSD“ auch eine Prüfung auf Aktualität erfolgt. Diese Vereinfachung in der Betrachtung ist zulässig, weil dadurch die Last allenfalls geringfügig überschätzt wird. Die daraus resultierenden Vorgaben für die Produkttypen sind dann hinreichend, um die die tatsächliche Last abzudecken. Im Lastmodell werden daher nur die ersten beiden Anwendungsfälle aus Tabelle "Tab_VSDM Anwendungsfälle" berücksichtigt.

4.1.3 Kommunikation Leistungserbringer (KOM-LE)

Für KOM-LE als sicheres Übermittlungsverfahren (SÜV) werden folgende performance-relevante Anwendungsfälle (siehe [gemSysL_KOM-LE]) betrachtet:

• Senden einer Nachricht, inklusive Schutz durch Signatur und Verschlüsselung
• Abholen einer Nachricht, inklusive Signaturprüfung und Entschlüsselung

Die Kommunikation zwischen KOM-LE-Clientmodul und KOM-LE-Fachdienst erfolgt über einen sicheren Kanal. Da ein einmal aufgebauter sicherer Kanal zum Senden und Empfangen mehrere Nachrichten verwendet werden kann, wird der Aufbau des sicheren Kanals im Folgenden als separater Anwendungsfall betrachtet.

Die eventuell notwendige Nachrichtenweiterleitung von dem KOM-LE-Fachdienst des Senders zum KOM-LE-Fachdienst des Empfängers findet asynchron sowohl zum Sende- als auch zum Abholprozess statt und wird daher separat behandelt.

Hinweis: In der Version KOM-LE 1.0 ist die Nachrichtengröße auf 25 MB begrenzt. Ab KOM-LE 1.5 ist es auch möglich E-Mail-Nachrichten mit Anhängen größer 25MB zu versenden bzw. zu empfangen. Der Mail-Body ohne Anhänge darf aber weiterhin die Größe von 25 MB nicht übersteigen und muss durch das KOM-LE-Clientmodul und den KOM-LE-Fachdienst verarbeitet werden.

4.1.4 Notfalldaten-Management (NFDM)

Das Notfalldaten-Management (NFDM) umfasst folgende performance-relevanten Anwendungsfälle (siehe [gemSysL_NFDM]), die vom Primärsystem aufgerufen werden.

• Signieren Notfalldaten
• Speichern Notfalldaten
• Lesen Notfalldaten
• Löschen Notfalldaten
• Speichern Persönliche Erklärungen
• Lesen Persönliche Erklärungen
• Löschen Persönliche Erklärungen

Notfalldaten (NFD) haben eine maximale Größe von 11,5 KB. Die Persönlichen Erklärungen (DPE) haben eine maximale Größe von 1,5 KB.

4.1.5 eMP/AMTS-Datenmanagement

Das eMP/AMTS-Datenmanagement umfasst folgende performance-relevanten Anwendungsfälle (siehe [gemSysL_AMTS_A]), die vom Primärsystem aufgerufen werden.

• eMP/AMTS-DATEN von eGK lesen
• eMP/AMTS-DATEN auf eGK schreiben

Die auf der eGK gespeicherten eMP/AMTS-Daten haben auf der eGK eine maximale Größe von 13,56 KB. Im XML-Format haben sie eine Größe von etwa 30 KB.

4.1.6 Elektronische Patientenakte (ePA)

Für die elektronische Patientenakte werden die sechs folgenden performance-relevanten Anwendungsfälle aus [gemSysL_ePA] betrachtet:

• Login durch einen Leistungserbringer/Versicherten
• Ad-hoc-Berechtigung durch einen Leistungserbringer anfordern
• Dokument durch einen Leistungserbringer/Versicherten suchen
• Dokument durch einen Leistungserbringer/Versicherten anzeigen
• Dokument durch einen Leistungserbringer/Versicherten einstellen
• Dokument durch einen Leistungserbringer/Versicherten löschen

Es wird davon ausgegangen, dass beim Aufruf einer Fachoperation implizit der Aufbau einer Aktensession inkl. Login durch einen Leistungserbringer/Versicherten erfolgt. Ebenfalls wird angenommen, dass die Dokumentengröße zwischen 10 KB und 1 MB beträgt. Es wird erwartet, dass es sich bei den 10 KB Dokumenten um NFD/DPE- und eMP- Dokumente handelt. Arzt- und Entlassbriefe werden mit einer Dokumentengröße größer 100 KB geschätzt. Die Dokumentengröße weiterer medizinische Informationsobjekte ist nicht abschätzbar, überschreitet aber auch nicht 1 MB. Die maximale erlaubte Dokumentengröße beträgt 25 MB.

4.1.7 Tokenbasierte Authentisierung (TBAuth)

[verschoben in 3.x.1.1 Lastmodell IDP-Dienste]

4.1.8 Lastmodell auf Ebene der Anwendungsfälle

Das Lastmodell verknüpft die zu erwartende Anfragerate je Anwendungsfall mit Mengengrößen aus dem Mengengerüst per Proportionalitätsfaktor und nennt die jeweils bearbeiteten Datenmengen.

Da hier Zahlen zu Annahmen über das Benutzerverhalten einfließen, die grundsätzlich nicht exakt vorhersagbar sind, wird mit Sicherheitsfaktoren gearbeitet (siehe „Spitzenlasterhöhung“ unten).

Lastmodell: Nutzung bestehender Anwendungen und Netze

Für die Nutzung bestehender Anwendungen und Netze liegt die Leistung der TI-Plattform auf Netzwerkebene. Tabelle "Tab_Lastmodell: Nutzung bestehender Anwendungen und Netze" gibt die Spitzenlast hierfür an.

Tabelle 23: Tab_Lastmodell: Nutzung bestehender Anwendungen und Netze

Lastmodell: VSDM-Anwendungsfälle und die davon unabhängige Nutzung der Basisdienste

Für VSDM und die davon unabhängige Nutzung der Basisdienste QES, digitale Signatur und Verschlüsselung wird die Spitzenlast auf Ebene der Anwendungsfallaufrufe durch die folgenden vier Tabellen definiert.

Tabelle "Tab_Lastmodell VSDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs" basiert auf den Zahlen der Lastmodellierung aus [gemSpec_Intermediär_VSDM]. In die angegebene Spitzenlast fließen die Zahl der Online-Prüfungen pro Quartal, die Anzahl der Versicherten und die Modellannahme einer Häufung der Online-Abfragen in der ersten Quartalswoche ein. Die angegebenen Datenmengen ergeben sich aus den pro Anwendungsfall summierten http-Nachrichtengrößen (d.h. http-body gemäß [gemSpec_Intermediär_VSDM] zuzüglich 200 Byte http-header).

Die Spalten „Spitzenlasterhöhung“ in den folgenden Tabellen geben an, um welchen Faktor die Spitzenlast pro Stunde gegenüber der Gleichverteilung der „Spitzenlast pro Tag“ über den Arbeitstag erhöht ist, wobei die Dauer des Arbeitstags ohne Beeinträchtigung der Allgemeinheit für die Modellbetrachtung in Tabelle "Tab_Mengengerüst: Annahmen für Modellierung" festgelegt wird. Für das Krankenhaus motiviert sich die Spitzenlasterhöhung beispielsweise bei den VSDM-Anwendungsfällen stationär dadurch, dass zwischen 9 und 14 Uhr etwa 70 % der Patienten aufgenommen werden. Um solche bekannten, aber auch unbekannte systematische Erhöhungen gegenüber der Gleichverteilung der „Spitzenlast pro Tag“ über den Arbeitstag abzudecken, ist je Anwendungsfall ein Faktor angegeben, der sich aus der Häufigkeit des Anwendungsfalles ergibt. Damit hat der Faktor zugleich die Qualität eines Sicherheitsfaktors.

Zur Erläuterung des Faktors „Spitzenlasterhöhung“ wird an Hand von Tabelle "Tab_Lastmodell VSDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs" exemplarisch die Spitzenlast pro Tag für 1000 Versicherte für den Anwendungsfall „VSD Lesen mit Aktualisierungsprüfung ohne Update“ sowie die Spitzenlast pro Stunde berechnet, in die der „Spitzenlasterhöhungsfaktor“ einfließt:

Spitzenlast pro Tag = 0,10 * 1000 pro Tag = 100 pro Tag

Spitzenlast pro Stunde = 100 pro Tag / 8 Stunden pro Tag * 4 = 50 pro Stunde

Tabelle 24: Tab_Lastmodell VSDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs

Bei der Verteilung der Spitzenlasten aus Tabelle "Tab_Lastmodell VSDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs" auf die einzelnen Praxen und MVZs wird von einer Gleichverteilung der Versicherten auf alle Leistungserbringer und einer Verteilung der Leistungserbringer auf Praxen und MVZs gemäß Tabelle "Tab_Mengengerüst: Lokationen" ausgegangen.

Tabelle 25: Tab_Lastmodell der Basisdienste QES für Leistungserbringer (LE) Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs

Tabelle 26: Tab_Lastmodell der Basisdienste QES in Krankenhäuser mit stationären Fällen

Die Mengengrößen in „Mengengröße x“ in Tabelle "Tab_Lastmodell der Basisdienste QES für Leistungserbringer (LE) Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs" und Tabelle "Tab_Lastmodell der Basisdienste QES in Krankenhäuser mit stationären Fällen" verknüpfen die Anfrageraten (Spitzenlasten) mit den Mengengrößen aus Tabelle "Tab_Mengengerüst: Versicherte und Leistungserbringer".

Tabelle 27: Tab_Lastmodell: Krankenhäuser (Quelle: [DKG2010])

(*) Es sind zwei Situationen zu unterscheiden: In 2,5 % der Anwendungsfälle erfolgt ein Update und in 97,5 % der Anwendungsfälle erfolgt kein Update, wobei sich die prozentuale Aufteilung und die Nachrichtengrößen aus Tabelle "Tab_Lastmodell VSDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs" ergeben.

(**) Bei der QES wird für die Stapelgrößen angenommen, dass 75 % der Anwendungsfälle Stapelgröße 1 und 25 % die Stapelgröße 2 haben.

Die Mengengrößen in „Mengengrößen x und y“ in Tabelle "Tab_Lastmodell: Krankenhäuser" verknüpfen die Anfrageraten (Spitzenlasten) mit den Mengengrößen aus Tabelle "Tab_Mengengerüst: Krankenhäuser" und Tabelle "Tab_Mengengerüst: Klassen der Leistungserbringer(LE)-Umgebungen".

Lastmodell: KOM-LE-Anwendungsfälle

Die erwartete Nutzungsrate der KOM-LE-Anwendungsfälle wird in Tabelle "Tab_Lastmodell KOM-LE-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs" für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs beschrieben sowie in Tabelle "Lastmodell: KOM-LE in Krankenhäusern" für die Ärzte in den Krankenhäusern. Die angegebenen Spitzenlasten skalieren jeweils mit Anzahl der KOM-LE-Teilnehmer oder der Zahl der stationären Fälle im KH pro Tag.

Zwei besondere Lastsituationen sind ergänzend zur Durchschnittsbetrachtung berücksichtigt:

• Große Nachrichten:  
  1% der Teilnehmer sendet je 100 Nachrichten je 25 MB über den Tag verteilt.
  Für diesen besonderen Nutzungsbedarf wird von einer Transportnetzanbindung von 16 Mbit/sec in Download-Richtung und 1 Mbit/sec in Upload-Richtung ausgegangen.
• Viele Nachrichten:
  1% der Teilnehmer sendet je 800 Nachrichten je 50 KB über den Tag verteilt.

Tabelle 28: Tab_Lastmodell KOM-LE-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs

Tabelle 29: Tab_Lastmodell: KOM-LE in Krankenhäusern

Annahme: KOM-LE-Teilnehmer in Krankenhausumgebung sind die in Tabelle "Tab_Mengengerüst: Krankenhäuser" und Tabelle "Tab_Mengengerüst: Klassen der Leistungserbringer(LE)-Umgebungen" aufgeführten „Ärzte“.

Die erwartete Nutzungsrate der KOM-LE-Anwendungsfälle für Nachrichten mit Anhängen größer 25 MB ist in Tabelle "Tab_Lastmodell: KOM-LE-Anwendungsfälle für große Nachrichten" dargestellt.

Tabelle 30: Tab_Lastmodell: KOM-LE-Anwendungsfälle für große Nachrichten

In der Lastbetrachtung wird davon ausgegangen, dass für den Anwendungsfall: "Bilder oder andere Aufnahmen zur Diagnostik empfangen" es je Sender 3 Empfänger gibt. Für den Anwendungsfall: "Sonstige Große Anhänge in Mail empfangen" wird angenommen, dass es je Sender 2 Empfänger gibt.

Lastmodell: NFDM-Anwendungsfälle

Die erwartete Nutzungsrate der NFDM-Anwendungsfälle wird in Tabelle "Tab_Lastmodell NFDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs" für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs beschrieben sowie inkludiert in Tabelle "Tab_Lastmodell: Krankenhäuser" für die Ärzte in den Krankenhäusern. Die angegebenen Spitzenlasten skalieren jeweils mit Anzahl der Ärzte oder der Zahl der ambulanten und stationären Fälle im KH pro Tag.

Dabei ergibt sich der Lastbeitrag für die Krankenhäuser zu Tabelle "Tab_Lastmodell: Krankenhäuser" wie folgt: Für das Prüfen der qualifizierten Arztsignatur wird für Prüfung der Signatur im Kontext Notfalldaten ein Faktor 0,25 (ambulant und stationär) und für Prüfung der Signatur beim Austausch von signierten Dokumenten zwischen den Krankenhäusern ein weiterer Faktor 0,25 (stationär) angesetzt.

Tabelle 31: Tab_Lastmodell NFDM-Anwendungsfälle für Ärzte, Zahnärzte und Psychotherapeuten in Praxen und MVZs

Lastmodell: Für eMP/AMTS-Anwendungsfälle

Die erwartete Nutzungsrate der eMP/AMTS-Anwendungsfälle wird in Tabelle "Tab_Lastmodell eMP/AMTS-Anwendungsfälle in Praxen und Apotheken" für Praxen (Mengengröße M13) und Apotheken (Mengengröße M25) beschrieben. In einzelnen Apotheken müssen parallel an 10 Arbeitsplätzen für jeweils verschiedene eGKs die Vorgänge „eMP/AMTS-Daten von eGK lesen und dann schreiben“ ausgeführt werden können.

Tabelle 32: Tab_Lastmodell eMP/AMTS-Anwendungsfälle in Praxen und Apotheken

Hinweis: G(iga), M(ega), K(ilo) bezeichnet hier G=(1024)³, M=(1024)² und K=(1024)¹.

Lastmodell: Für ePA-Anwendungsfälle

Die Tabelle "Tab_Lastmodell ePA aus der LE-U für Praxen, Apotheken und Krankenhäuser" stellt eine Übersicht über die zu erwartenden Nutzungsraten für ePA dar.

Tabelle 33: Tab_Lastmodell ePA aus der LE-U für Praxen, Apotheken und Krankenhäuser

Die Mengengröße der ePA-Teilnehmer bezieht sich auf die Tabelle "Tab_Mengengerüst: Lokationen". Unter der erwarteten Anzahl an Anwendungsfällen pro Tag je LEI wird zum Beispiel das Einstellen eines Arztbriefes verstanden. In der Modellbetrachtung ist für die Anzahl der Anwendungsfälle pro Tag ein Sicherheitsfaktor von 2 mit eingerechnet.

In Praxen und Krankenhäusern wird erwartet, dass die verwendeten Dokumenttypen eMP, NFD/DPE, Arzt- und Entlassbriefe in ePA Anwendung finden. In den Apotheken wird davon ausgegangen, dass ausschließlich ePA-Anwendungsfälle mit dem Medikationsplan erfolgen.

Gemäß Kapitel 3.1.6 wird davon ausgegangen, dass die durchschnittliche Dokumentgröße der Dokumenttypen eMP und NFD/DPE 10 KB beträgt. Arzt- und Entlassbriefe werden mit einer durchschnittlichen Dokumentgröße von 1 MB angenommen.

(*) Die Anzahl der im Krankenhaus ausgestellten Entlassbriefe ist abhängig von der Anzahl der stationären Fälle pro Tag und somit von der Größe der Leistungserbringer-Umgebung (LE-U) gemäß Tabelle "Klassen der Leistungserbringer(LE)-Umgebungen".

Zusätzlich wird vermutet, dass jeder gesetzlich Versicherte (70 Mio.) einmal im Jahr bei seiner gesetzlichen Krankenkasse eine Versichertenauskunft (Auskünfte an Versicherte) beantragt.

In Tabelle "Tab_ePA-Anwendungsfälle je LE-U" wird die erwartete Anzahl an ePA-Anwendungsfälle pro Tag je Leistungserbringer-Umgebung dargestellt.

Tabelle 34: Tab_ePA-Anwendungsfälle je LE-U

Es sind in LE-U1 fünf Arztbriefe und 19 Entlassbriefe mit eingerechnet, da LE-U1 gemäß Tabelle "Klassen der Leistungserbringer(LE)-Umgebungen" Praxen, Gemeinschaftspraxen, MVS und KH klassifiziert.

Die Anzahl der Entlassbriefe pro Tag für die LE-U2 – LE-U4 ergeben sich aus der Anzahl der stationären Fälle pro Tag addiert mit den fünf Arztbriefen aus LE-U1. Somit werden neben Entlassbriefen auch Arztbriefe in den jeweiligen LE-U mit berücksichtigt.

Die zu erwartete Nutzungsrate aus der Versicherten-Umgebung wird in Tabelle "Tab_Lastmodell ePA aus der Versicherten-Umgebung" dargestellt.

Tabelle 35: Tab_Lastmodell ePA aus der Versicherten-Umgebung

Hierbei wird davon ausgegangen, dass im Maximalausbau etwa 35 Mio. gesetztlich Krankenversicherte die Fachanwendung ePA von der Versicherten-Umgebung nutzen werden. Es wird je Versicherter eine Anzahl  von 17 Dokumenten pro Jahr erwartet.

Es wird geschätzt, dass je Akte pro Versicherter ein Speicherbedarf von a. 300 MB pro Jahr notwendig ist.

4.1.9 Betriebliche Anwendungsfälle

Betrieblicher Anwendungsfall: Update des Konnektors bzw. der Kartenterminals

Beim Ausrollen von Software auf Konnektor und Kartenterminals müssen durch Download vom Konfigurationsdienst Softwarepakete auf die Konnektoren verteilt werden. Tabelle "Tab_Mengenrahmen „Update Konnektor und Kartenterminals“" listet die Annahmen, die für den Mengenrahmen dieses betrieblichen Anwendungsfalls getroffen werden.

Tabelle 36: Tab_Mengenrahmen „Update Konnektor und Kartenterminals“

4.2 Bearbeitungszeiten

Der anwendungsfallübergreifende Bedarf für die Bearbeitungszeiten an den Außenschnittstellen der TI-Plattform wurde für den Erwartungswert pro Schnittstellenoperation abgestimmt.

Die Abstimmung erfolgte zweistufig, um Machbarkeit/Wirtschaftlichkeit und Bedarf in Einklang zu bringen. Im ersten Schritt wurden per Expertenschätzung die Leistungswerte für eine wirtschaftlich günstige Lösung bestimmt. Im zweiten Schritt wurde geprüft, ob mit diesen Leistungswerten der Bedarf der Fachanwendungen erfüllt werden kann.

Für den Produkttyp Konnektor kommen Bearbeitungszeiten durch das Fachmodul hinzu [gemSpec_FM_VSDM].

Für die Transportnetzanbindung über den Konnektor an Zentrale Dienste der TI-Plattform und Fachanwendungsspezifische Dienste setzt das Performance-Modell typische Bandbreiten an, die dann in Anforderungen zu Bearbeitungszeiten einfließen: Für Praxen einen asymmetrischen Zugang von 1024 kbit/sec in Download-Richtung und 128 kbit/sec in Upload-Richtung (mit Round-Trip-Time von 50 msec) für Krankenhäuser einen symmetrischen Zugang von 2048 kbit/sec in Upload- und Download-Richtung (mit Round-Trip-Time von 40 msec).

4.2.1 Bearbeitungszeiten KOM-LE

Für KOM-LE müssen unter den oben genannten Rahmenbedingungen die Mittelwerte der Bearbeitungszeiten pro Anwendungsfall kleiner oder gleich den in Tabelle "Tab_Bearbeitungszeitvorgaben KOM-LE je Anwendungsfall" angegebenen Mittelwerten sein.

Tabelle 37: Tab_Bearbeitungszeitvorgaben KOM-LE je Anwendungsfall

(*) nicht relevant für die Bearbeitungszeit

(**) Nachrichten müssen spätestens 10 Minuten nach dem erfolgreichen Versenden zum Abruf für den Empfänger bereitstehen.

4.2.2 Bearbeitungszeiten Notfalldaten-Management (NFDM)

Für NFDM müssen im stationären Einsatz unter den oben genannten Rahmenbedingungen die Mittelwerte der Bearbeitungszeiten pro Anwendungsfall kleiner oder gleich den in Tabelle "Tab_Bearbeitungszeitvorgaben NFDM je Anwendungsfall" angegebenen Mittelwertschranken sein.

Tabelle 38: Tab_Bearbeitungszeitvorgaben NFDM je Anwendungsfall

Für die Einsätze im mobilen Bereich sollen diese Vorgaben ebenfalls erreicht werden. Priorität hat der Anwendungsfall „NFD lesen“.

4.2.3 Bearbeitungszeiten eMP/AMTS-Datenmanagement

Für eMP/AMTS müssen unter den oben genannten Rahmenbedingungen die Mittelwerte der Bearbeitungszeiten pro Anwendungsfall kleiner oder gleich den in Tabelle "Tab_Bearbeitungszeitvorgaben eMP/AMTS je Anwendungsfall" angegebenen Mittelwertschranken sein.

Tabelle 39: Tab_Bearbeitungszeitvorgaben eMP/AMTS je Anwendungsfall

4.2.4 Bearbeitungszeiten elektronische Patientenakte (ePA)

Für ePA müssen unter den oben genannten Rahmenbedingungen der Mittelwerte der Bearbeitungszeit pro Anwendungsfall kleiner oder gleich den in Tabelle "Tab_ePA Bearbeitungszeitvorgaben je Anwendungsfall" angegebenen Mittelwertschranken sein.

Es werden nur die Anwendungsfälle betrachtet, die häufig in der LE-Umgebung Anwendung finden.

Tabelle 40: Tab_ePA Bearbeitungszeitvorgaben je Anwendungsfall

(*) nicht relevant für die Bearbeitungszeit

(**) Für das Anzeigen und Einstellen von 25 MB-Dokumenten in der LEI-Umgebung wird von einer Transportanbindung von 16 Mbit/s in Download-Richtung und 1024 Kbit/s in Upload-Richtung ausgegangen. 

Es wird bei den Anwendungsfällen "Dokument in der LEI suchen, löschen, anzeigen und einstellen" davon ausgegangen, dass ein Login bereits durchgeführt wurde. Sofern kein Login durchgeführt wurde, muss die Bearbeitungszeit für die Durchführung eines Logins mit berücksichtigt werden.

4.2.5 Bearbeitungszeiten Tokenbasierte Authentisierung

[verschoben in 3.x.1.2 Bearbeitungszeiten IDP-Dienste]

4.3 Verfügbarkeiten

Die zu fordernde Verfügbarkeit richtet sich am Bedarf der Anwendungsfälle aus. Der höchste Bedarf entsteht in großen Krankenhäusern. Prinzipiell begrenzendes Element für die Verfügbarkeit ist das Transportnetz. Einzelne Krankenhäuser können sich für das obere Ende der am Markt erhältlichen Verfügbarkeit entscheiden, die mit 99,5 % angenommen wird. Es wird weiter angenommen, dass diese großen Krankenhäuser in der Lage sind, die Verfügbarkeit für Clientsystem und Konnektor mit Kartenterminals auf jeweils 99,9 % zu halten. Ist die Verfügbarkeit des Backend etwa genau so groß wie der für große Krankenhauseinrichtungen mögliche Beitrag von 99,3 %, dann wird ein ausgewogener Wert erreicht.

Tabelle "Tab_Erzielbare Anwendungsfallverfügbarkeit für ein Krankenhaus" zeigt die so für den Anwendungsfall „VSD Lesen mit Aktualisierungsprüfung ohne Update“ erzielbare Gesamtverfügbarkeit von 98,5 %, die einer Ausfallzeit pro Monat von kleiner 7 Stunden entspricht. Sie ist notwendig und tragbar.

Tabelle 41: Tab_Erzielbare Anwendungsfallverfügbarkeit für ein Krankenhaus

Für die Produkttypen der dezentralen Zone wird erwartet, dass sie selten ausfallen und in diesen seltenen Fällen rasch austauschbar sind. So wird erwartet [DKG2010], dass ein Konnektor, der im Krankenhaus eingesetzt wird, innerhalb von 15 Minuten ausgetauscht werden kann.

Die Tabelle "Tab_Erzielbare Anwendungsfallverfügbarkeit für ein Krankenhaus im Kontext von E-Rezept" zeigt beispielhaft für den Anwendungsfall „E-Rezept einstellen“ eine erzielbare Gesamtverfügbarkeit von 99,90 %, die einer Ausfallzeit pro Monat von kleiner 7 Minuten entspricht.

Tabelle 42: Tab_Erzielbare Anwendungsfallverfügbarkeit für ein Krankenhaus im Kontext von E-Rezept

5 Leistungsanforderungen an die Produkttypen der TI

Das vorliegende Kapitel definiert die Leistungsanforderungen bzgl. der drei Performance-Dimensionen Durchsatz, Bearbeitungszeit und Verfügbarkeit für Produkttypen der TI. Die Anforderungen ergeben sich aus den in Kapitel 3 formulierten Bedarfen.

Grundlagen für die Performance-Vorgaben sind

• die in Kapitel 3 formulierten Bedarfe,
• die Definition der Produkttypen der TI-Plattform [gemKPT_Arch_TIP#5.2],
• die Definition ihrer Außenschnittstellen⁴ [gemKPT_Arch_TIP#5.3 und 5.4],
• die Nutzung der TI-Plattform-Operationen durch VSDM-Anwendungsfälle,
• die Annahmen zu Caching-Dauern in Tabelle "Tab_Caching-Dauer"

⁴⁾ Im Rahmen der Produkttypspezifikationen werden die konzeptionellen Schnittstellen aus [gemKPT_Arch_TIP] durch technische Schnittstellen umgesetzt. Die Zuordnung der technischen auf die konzeptionellen Schnittstellen erfolgt in den Produkttypspezifikationen.

Tabelle 43: Tab_Caching-Dauer

Alle Spitzenlastvorgaben beziehen sich auf den Produktivbetrieb mit 70 Mio. Versicherten.

Die Spitzenlastvorgaben für einen Produkttypen beziehen sich, soweit nicht explizit anders angegeben, auf alle Produktinstanzen des Produkttypen in Summe.

Bearbeitungszeitvorgaben unter Last

Aus Bedarfssicht sollen alle Produkttypen die Vorgaben für Bearbeitungszeiten unabhängig von den Vorgaben für ihr Lastverhalten erfüllen. D.h. dass die Bearbeitungszeitvorgaben letztlich unter Volllast erfüllt werden sollen.

Um die Überprüfbarkeit der Anforderungen beherrschbar zu halten, wird dieser Zusammenhang systematisch betrachtet und unter Beachtung der Bedarfssicht vereinfacht. Abbildung 5 unterscheidet hierzu vier Typen von Anforderungen danach, wie sehr die Anforderungen bzgl. Bearbeitungszeit und Lastverhalten ineinandergreifen.

Abbildung 5: Quadranten der Kombination aus Bearbeitungszeit- und Lastanforderungen

Im einfachsten Fall (Quadrant 1) werden keine Anforderungen an Bearbeitungszeit und Lastverhalten gestellt, weil kein besonderer Überprüfungsbedarf jenseits funktionaler Tests besteht, etwa für Administrationsfunktionen, die weder mit einer nennenswerten Last ausgeführt werden noch notwendigerweise Bearbeitungszeitvorgaben einhalten müssen.

Im Quadrant 2 sind Anforderungen gruppiert, die dafür sorgen, dass die Produkttypen den benötigten Durchsatz (z. B. [GS-A_4161]) erreichen. Das betrifft ausschließlich Produkttypen der zentralen Zone der TI-Plattform.

Im Quadrant 3 sind Anforderungen gruppiert, die für jede Schnittstellen-Operation eines Produkttypen die lastfreie Einhaltung der Bearbeitungszeitvorgaben fordern (z. B. [GS-A_4346]).

Im Quadrant 4 sind schließlich Anforderungen gruppiert, welche die Einhaltung von Bearbeitungszeitvorgaben unter Last verlangen (z. B. [GS-A_4157], [GS-A_4159], [GS-A_4162] für Produkttypen der zentralen Zone der TI-Plattform).

5.1 Produkttypen der dezentralen Zone der TI-Plattform

An die Produkttypen der dezentralen Zone werden keine expliziten Verfügbarkeitsanforderungen gestellt⁵.

⁵⁾ Ausnahme Konnektor für Krankenhäuser.

5.1.1 Produkttypen eGK, HBA, SMC-B, SMC-K, SMC-KT

Performance-Anforderungen an die Smartcards im Gesundheitswesen werden im Rahmen der Kartenspezifikationen gestellt.

5.1.2 Produkttyp Konnektor

Der Produkttyp Konnektor muss alle Einsatzumgebungen von einer Arztpraxis bis zu großen Krankenhäusern abdecken. Diese unterteilt Tabelle "Tab_Mengengerüst: Klassen der Leistungserbringer(LE)-Umgebung" in vier Klassen von Leistungserbringerumgebungen (LE-U1, LE-U2, LE-U3, LE-U4). Über das Lastmodell aus Kapitel 3.1.8 erhält man je Leistungserbringerumgebung die für jede Schnittstellenoperation des Konnektors zu erwartende Spitzenlast.

Tabelle "Tab_gemSpec_Perf_Konnektor" listet je Schnittstellenoperation zu den Spitzenlastvorgaben die Vorgabenwerte für Bearbeitungszeiten. Die Bearbeitungszeiten beinhalten die an den Kartenterminals und Karten anfallenden Zeiten, was der Steuerungsverantwortung des Konnektors Rechnung trägt.

Die im Folgenden formulierten Anforderungen sind so angelegt, dass sie die Vorgabenwerte möglichst gut erfüllen, aber auch die Machbarkeitsgrenzen berücksichtigen, die etwa beim konkurrierenden Zugriff des Konnektors auf eine SMC-B bestehen.

Tabelle 44: Tab_gemSpec_Perf_Konnektor – Last- und Bearbeitungszeitvorgaben